Skip to content

borp/sa: Update borp to pass Transaction args through BoulderTypeConverter #8494

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Nov 19, 2025
Merged

borp/sa: Update borp to pass Transaction args through BoulderTypeConverter #8494

merged 1 commit into from
Nov 19, 2025

Conversation

@beautifulentropy
Copy link
Member

@beautifulentropy beautifulentropy commented Nov 18, 2025 •
edited
Loading

Today, timestamp truncation happens for queries using *borp.DbMap but not *borp.Transaction. That means comparisons still see sub-seconds, but inserts into MariaDB DATETIME columns silently truncate them to whole seconds.

On MySQL 8, the same queries will still include sub-seconds, but inserts into DATETIME columns will round to the nearest second instead of truncate. This leads to issues for queries like the one in *StorageAuthority.UpdateCRLShard(). When two CRL updaters write within the same second one may be rounded up to the next second. When the other updater attempts its own UPDATE .. WHERE thisUpdate <= ?, the condition fails because the stored timestamp now appears to be in the future.

Ahead of the transition from ProxySQL + MariaDB to Vitess + MySQL 8 in #8468, update borp (letsencrypt/borp#12) to expose Transaction arguments to the BoulderTypeConverter, allowing it to truncate all timestamps passed through Transactions and keep behavior consistent across *borp.DbMap and *borp.Transaction, as well as MariaDB and MySQL 8.

Part of #7736

Example of truncation vs rounding behavior in MariaDB and MySQL 8, respectively:

MariaDB> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected, 1 warning (0.004 sec)

MariaDB> CREATE TABLE t1 (
    ->   id INT AUTO_INCREMENT PRIMARY KEY,
    ->   ts DATETIME(0)
    -> );
Query OK, 0 rows affected (0.003 sec)

MariaDB> INSERT INTO t1 (ts) VALUES
    ->   (‘2025-01-01 12:00:00.001’),
    ->   (‘2025-01-01 12:00:00.499’),
    ->   (‘2025-01-01 12:00:00.500’),
    ->   (‘2025-01-01 12:00:00.501’),
    ->   (‘2025-01-01 12:00:00.900’);
Query OK, 5 rows affected (0.000 sec)
Records: 5  Duplicates: 0  Warnings: 0

MariaDB> SELECT id, ts FROM t1 ORDER BY id;
+----+---------------------+
| id | ts                  |
+----+---------------------+
|  1 | 2025-01-01 12:00:00 |
|  2 | 2025-01-01 12:00:00 |
|  3 | 2025-01-01 12:00:00 |
|  4 | 2025-01-01 12:00:00 |
|  5 | 2025-01-01 12:00:00 |
+----+---------------------+
5 rows in set (0.001 sec)
mysql> DROP TABLE IF EXISTS t1;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> CREATE TABLE t1 (
    ->   id INT AUTO_INCREMENT PRIMARY KEY,
    ->   ts DATETIME(0)
    -> );
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t1 (ts) VALUES
    ->   (‘2025-01-01 12:00:00.001’),
    ->   (‘2025-01-01 12:00:00.499’),
    ->   (‘2025-01-01 12:00:00.500’),
    ->   (‘2025-01-01 12:00:00.501’),
    ->   (‘2025-01-01 12:00:00.900’);
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> SELECT id, ts FROM t1 ORDER BY id;
+----+---------------------+
| id | ts                  |
+----+---------------------+
|  1 | 2025-01-01 12:00:00 |
|  2 | 2025-01-01 12:00:00 |
|  3 | 2025-01-01 12:00:01 |
|  4 | 2025-01-01 12:00:01 |
|  5 | 2025-01-01 12:00:01 |
+----+---------------------+
5 rows in set (0.00 sec)

@beautifulentropy beautifulentropy mentioned this pull request Nov 18, 2025
Open
@beautifulentropy beautifulentropy marked this pull request as ready for review November 18, 2025 17:09
@beautifulentropy beautifulentropy requested a review from a team as a code owner November 18, 2025 17:09
@beautifulentropy beautifulentropy merged commit 1f6ec8c into main Nov 19, 2025
20 of 22 checks passed
@beautifulentropy beautifulentropy deleted the upgrade-borp branch November 19, 2025 14:59
npurtova pushed a commit to plesk/boulder that referenced this pull request Nov 25, 2025
@beautifulentropy
borp/sa: Update borp to pass Transaction args through BoulderTypeConv…
4e0dce3 
…erter (letsencrypt#8494)

Today, timestamp truncation happens for queries using `*borp.DbMap` but
not `*borp.Transaction`. That means comparisons still see sub-seconds,
but inserts into MariaDB `DATETIME` columns silently truncate them to
whole seconds.

On MySQL 8, the same queries will still include sub-seconds, but inserts
into `DATETIME` columns will round to the nearest second instead of
truncate. This leads to issues for queries like the one in
`*StorageAuthority.UpdateCRLShard()`. When two CRL updaters write within
the same second one may be rounded up to the next second. When the other
updater attempts its own `UPDATE .. WHERE thisUpdate <= ?`, the
condition fails because the stored timestamp now appears to be in the
future.

Ahead of the transition from ProxySQL + MariaDB to Vitess + MySQL 8 in
letsencrypt#8468, update borp (letsencrypt/borp#12) to
expose Transaction arguments to the BoulderTypeConverter, allowing it to
truncate all timestamps passed through Transactions and keep behavior
consistent across `*borp.DbMap` and `*borp.Transaction`, as well as
MariaDB and MySQL 8.

Part of letsencrypt#7736
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jsha jsha jsha approved these changes

@aarongable aarongable aarongable approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@beautifulentropy @jsha @aarongable